home *** CD-ROM | disk | FTP | other *** search
/ Software Explosion 2 / Software Explosion 2 - Virtual Computer Pets (1997).iso / system / c / lowfrag.readme < prev    next >
Encoding:
Text File  |  1996-01-14  |  8.2 KB  |  215 lines
  1. LowFrag v1.2 (1-Feb-96)  -  By Eric Sauvageau.
  2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  3.  
  4. 0. History
  5. ~~~~~~~~~~
  6.    1.0 - First version - limited release.
  7.  
  8.    1.2 - Wouldn't work if no threshold value was specified from the command
  9.          line.
  10.  
  11.        - Fixed major enforcer hits :(
  12.  
  13.  
  14.  
  15. 1. Introduction
  16. ~~~~~~~~~~~~~~~
  17. "Out of Memory" the program told you.  What the heck?!  You have 2 megs of
  18. memory, 1 of which is free, and this 300 Kb program tells you 
  19. "Out of Memory"?  Then you open a Shell, type "Avail" and press Return.
  20. And Avail tells you this:
  21.  
  22.  
  23. Type  Available    In-Use   Maximum   Largest
  24. chip    1004888   1091240   2096128    207000
  25. fast          0         0         0         0
  26. total   1004888   1091240   2096128    207000
  27.  
  28.  
  29. This is called "memory fragmentation".  You have a "playground" of
  30. 2 Megabytes of RAM, but little programs are playing all over it, leaving
  31. only small areas free between each of them rather than one large free area.
  32. Yes, programs are like kids, they love to scatter everywhere.
  33.  
  34.  
  35. Unfortunately, it's pratically impossible to "unfrag" memory on the Amiga.
  36. Best thing you can do is to try an "Avail Flush" in a Shell, hoping that it 
  37. will remove a library from memory, allowing two small areas of 200 Kb each 
  38. to join together into a 400 Kb large area, the library separating them
  39. being freed from memory.
  40.  
  41. Ok, so we can't unfrag memory.  How about giving a little more organization
  42. to these "kids", telling them to play together rather than scattering all
  43. over the playground?  Well, it ain't that simple.  Kids never listens.
  44. You know this, you've been there too.
  45.  
  46.  
  47. Fortunately, the memory "playground" has a little more order than a 
  48. playground invaded by kids.  Before getting access to the "playground", 
  49. you must ask Mr. Exec if you can go play on it, and where to play.  But 
  50. you see, Mr. Exec is very busy watching Mrs. Paula sunbathing on the other
  51. side of the park, so he's doing a quick'n'dirty job: he starts looking 
  52. from the closest area, spots the first area large enough for the one
  53. asking for space, and directs it there.  And Mr. Exec goes back to the 
  54. sight of Mrs. Paula, sunbathing in a tiny bikini.
  55.  
  56.  
  57.  
  58. 2. But I have an Amiga, no a kid playground!
  59. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  60. This is how Exec works.  When a program needs a memory area for its code 
  61. or data, it asks Exec to assign it a free area, and goes there.  This is 
  62. what the DOS does when you load a program: it asks Exec for areas where it
  63. can put the program.  And then, the programs asks Exec for areas where it
  64. can put the various data, libraries, etc...  But problem is, when the 
  65. program leaves, some of the data can stay in memory:
  66.  
  67. 1) Files created in the Ram Disk.
  68. 2) Libraries/devices loaded.
  69. 3) Files in the clipboard, usualy located in the Ram Disk.
  70. 4) Areas "forgotten" by the program.
  71. 5) Small "patches" left in memory.
  72.  
  73. And there is surely a few other cases.
  74.  
  75. Or, another situation:  Two programs are loaded one after the other.  The
  76. first one leaves, but not the second one.  Result: an area of the size of
  77. the first program is left, separated from the remaining free memory by the
  78. second program.
  79.  
  80.  
  81. We can't really fix this problem.  But we can help reducing the number of
  82. situations where it can occur.  This is what LowFrag can do.
  83.  
  84.  
  85. 3. Soooo... What does LowFrag do?
  86. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  87. LowFrag will eliminate one of the cases where memory gets fragmented:
  88. the case where a program is loaded (100-500 Kb) in memory, and exists
  89. leaving some data behind it in memory (clipboard, libraries, etc...).
  90. Or when another program puts small allocations just after the large
  91. program, so when the large program quites, it leaves a rather large 
  92. block separated from the main area.
  93.  
  94. How does LowFrag works?
  95.  
  96. Usually, the data left in memory are small blocks (small when compared
  97. to the programs, that is).  So, we could reduce fragmentation by
  98. separating the large allocations (usually applications) from the smaller
  99. allocations (usually data, patches, etc...).  Exec's memory allocation 
  100. has a flag which will do just that:
  101.  
  102.    MEMF_REVERSE   -> Allocate memory starting from the top of memory.
  103.  
  104. When this flag is used on a memory request, Exec will start looking from
  105. the TOP of memory for a free area, rather than from the bottom (as usual).
  106. So, we can separate allocations by putting the "MEMF_REVERSE" flag to the
  107. smaller allocations, so they stay out of the way of the larger allocations.
  108.  
  109. This is what LowFrag does.  When an allocation is larger than a threshold
  110. value, the allocation gets "stamped" with a "MEMF_REVERSE" flag, telling
  111. Exec to find it a suitable area by starting from the top of memory.  So 
  112. when the application leaves, any smaller allocations left in memory won't
  113. clutter the area usually needed by large.
  114.  
  115. Here's a concrete case that I tested myself where LowFrag reduce 
  116. fragmentation:
  117.  
  118.  
  119. 1) Launch a terminal (Terminus)  - Around 400 Kb
  120. 2) Cut some text into the clipboard - A few bytes
  121. 3) Exit the terminal.
  122.  
  123. Without LowFrag: The memory is splitted by the clipboard content.  But
  124. with LowFrag, the clipboard content is at the top of the memory.  So rather
  125. than "cutting" a 400 Kb block from the main area, it will probably cut 
  126. around 10-50 Kb (small allocations done by the terminal: serial.device, 
  127. various libraries, etc...).  We can call this an improvement I guess :)
  128.  
  129.  
  130. 4. Sounds like fun... I want to use it!
  131. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  132. Simple: copy LowFrag in your C: directory, and somewhere in your
  133. startup-sequence (usually just after SetPatch), add this single line:
  134.  
  135. Run <>NIL: c:LowFrag value
  136.  
  137. value is the threshold limit: allocations smaller than this value will get
  138. "promoted" with MEMF_REVERSE.  If you don't put any value, then the default
  139. threshold of 32768 (32 Kb) will be used.  I found this value to work very
  140. well on my own system, so try the patch first with this value, adjusting it
  141. afterward to suit your system.
  142.  
  143.  
  144. LowFrag can be aborted at any time by sending it a CTRL-C code, altough 
  145. this isn't recommended: if another program patches AllocMem() or AllocVec()
  146. afterward, it's most likely that the system will crash.
  147.  
  148.  
  149. 5. That's it
  150. ~~~~~~~~~~~~
  151. So enjoy.  The whole thing is released as public domain.  If you have any
  152. ideas on how to improve the thing, the source code is there in the 
  153. archive (written in Amiga E, with some inline assembly), so just go ahead.
  154. A few possible ideas:
  155.  
  156.  - Promote allocations which has the flag MEMF_PUBLIC.
  157.  - Have the user define a list of tasks which should always get promoted
  158.    (altough this could probably slow down the system.  Memory allocation
  159.    is one of the cornerstones of the OS, so any changes there will reflect
  160.    on the whole system's performances.
  161.  
  162.  
  163. 6. Hints & tips for programmers
  164. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  165. You can help reducing the memory fragmentation problem.
  166.  
  167. a) When possible, use the memory pool system available since Exec V39
  168.    (it's been in amiga.lib since V33 I think?).
  169.  
  170. b) For large executables, split it into separate hunks, so they could
  171.    be loaded even on a fragmented system.
  172.  
  173. c) Make sure you don't leave anything behind when you quit your program,
  174.    unless when needed.  Testing for memory leaks should be part of every
  175.    debugging routine (Enforcer won't intercept by itself ALL kind of bugs,
  176.    guys.)
  177.  
  178. d) When doing an allocation meant to STAY in memory, why don't use the
  179.    MEMF_REVERSE flag?
  180.  
  181. e) For large applications, it is often a good idea to put part of the code
  182.    into a shared library, and keep the library open only when it is needed.
  183.    This way, it can be flushed from memory when the system needs more
  184.    memory.
  185.  
  186.  
  187. 7. The Author
  188. ~~~~~~~~~~~~~
  189. I can be reached via Fidonet:  Eric Sauvageau>1:242/907.0
  190.  
  191. Or via Internet, from a friend's account: dream@step.polymtl.ca
  192. (specify that the message is addressed to me).
  193.  
  194.  
  195. This whole little thing is released on the Public Domain.  Do whatever you 
  196. want with it.  As for I, I decline any responsability if you encounter 
  197. problems while using this patch.  It's been in use on my system and 
  198. a friend's for many weeks before I released it, without any problem.
  199.  
  200.  
  201. I also wrote a few other goodies for the Amiga:
  202.  
  203. TDPrefs  - Preferences editor for the trackdisk.device.
  204. MFormat  - Replacement for CBM's "Format" command.
  205. DevsMan  - Manager for the Devs: and Storage directories.
  206. XPKatana - GUI/ARexx interface for the XPK packing system.
  207.  
  208.  
  209. See ya!
  210.  
  211.  
  212.    Merlin
  213.    ------
  214.  
  215.